shawnreilly

Privacy is hard to quantify from a good/bad perspective because it relates to personal preference. One person might demand it, while another person might not care at all. Because of this, I don't see the issue as cut-and-dry as being good or bad. As a Community that builds Products, I think it is much more constructive to understand that the issue is broad in nature, and your customers likely have opposing views (or may not care at all). I think the real question should be; When building a Product, what are the ethical implications of User Privacy? If one believes that they should be in-tune with their customers (which is what I believe) then the best approach is probably to respect both sides of the issue. So in other words, instead of deciding what is "right", build the Product to support both extremes. When you give the User a choice, it is much more well received than making the choice for them. Most issues I've read about, heard about, or experienced myself resulted from a lack of understanding or respect for the User's choice.

I would not agree that previous iterations have failed to do anything meaningful. It is very hard to gauge the success of a non-assertion pledge or defensive patent pool. For example, if you take Google's Pledge of MapReduce related patents, one could argue that Google has helped accelerate innovation in the Big Data space. The resulting Businesses and Products, and their resulting Revenues and Market Caps could possibly be considered data points indicating success. The same could be said for the Open Invention Network and Linux, which has accelerated innovation in Infrastructure, Security, and many other industries. The problem is, it's hard to measure this success, and in many cases the benefits are not realized for quite some time.

I believe that the Open patent Foundation has the potential to do something meaningful because the Community will determine the scope, focus, and relating Licenses. This creates the potential to positively impact a large range of industries. This could apply to Technology, Software, Medicine, Energy, and many other industries where Patent Trolling or similar extortion related tactics have stalled innovation. The concept of an Open Patent License won't stop Patent Trolling overnight. But it will give the Community a standardized method to share future innovations, effectively providing the potential to accelerate innovation over time (from Today moving forward).

The underlying concepts and the approach are very similar. The idea of a non-assertion pledge (or defensive patent pool) is a refreshing example of forward thinking Businesses and Organizations that recognize the adverse effects that Patent Trolling has on innovation. Google is a great example [1]. The Open Patent Foundation takes this concept, and applies it with a different approach. Instead of choosing a specific focus or scope, we want to allow the Community (as a whole) to drive the creation of Open Patent License(s). The end result would be a set of Licenses that any Person or Organization could use and apply towards any Intellectual Property or Patents they may own. So some of them may end up being specific to Software. others may end up being specific to Utility Patents. And yet others might end up being non-specific in terms of application, but specific to a Time Period, or perhaps Distribution Guidelines. It would be up to the Community to decide what we want to use, and that is what (IMO) makes the entire concept so powerful. It is not implied to be a better approach, just a new one. In the end, all of these types of movements are positive. The end goal is to accelerate innovation and stop Patent Trolling.

http://www.google.com/patents/opnpledge/

At the last Startup Weekend Honolulu 2014, I introduced my approach towards solving this problem; The Open Patent Foundation (Non-Profit). Similar to concepts such as Creative Commons, and Open Source Software Licenses, the idea is to create Open Patent License(s) that standardize a method to share intellectual property with the Community. While this does not directly solve the problem, I think it is a necessary first step towards realizing that we (as a Community) can leverage the existing broken Patent System in a way that favors us (the Community). Not only does this have the potential to accelerate innovation, it will also prevent Patent Trolls from claiming ownership of innovations, and that's a big deal. These Trolls currently use a Licensing approach to extort people (pay our Licensing Fee or else we will sue). I think it would be ironic (and awesome) to use the same approach to effectively null Patent Trolls. Considering how ineffective Legal Reform is, this might be our best bet; To come together collectively as a Community and decide that we want to take a stand and start using the System in a new and different way. It would be a double win, accelerate innovation and null Patent Trolling. If this sounds interesting, the website is http://www.openpatentfoundation.com and I recently moved to Mountain View, so I'm looking to spend more time on this and see if we can get some Community Support.

Rackspace is another company that stands up to fight Patent Trolls. And they run OpenStack. (Double the Awesome)

I think it's possible, but it's rare. The HTML5/CSS3 Based App I'm working on right now does feel like a Native App, but it's because it was designed specifically to mitigate some of the "issues" with HTML5/CSS3 Apps. In terms of User Experience, one of the biggest factors is how the App is packaged and distributed. If it is a traditional Web App, then the UX will be heavily impacted while the content is downloaded from the Web. Especially if the connection is slow, and the content is rich. If the App is packaged as a Native App (which is what I'm doing), then most of the content is local, and only dynamic information needs to be downloaded. In this scenario, the UX is much more acceptable since most of the content does not need to be downloaded, it's already there. I'm using PhoneGap to package our App, and we've specifically crafted our API calls to be very light, so the resulting UX does have a Native Feel. But that does not mean that it's the same as Native, and once you get to that point, you'll find there are additional points that need to be addressed (mainly relating to the limitations of whatever javascript engine you use). Another point is the delay when clicking buttons. But the good news is, all these "issues" can be mitigated if you recognize them, and design the product accordingly. Very different approach from designing the Product without taking this into account, and then trying to "fix" it or "band-aid" it after the fact. Design it right from the start, and the differences become less and less apparent. So I guess my answer would be, not yet, but pretty soon!

In some cases, research does relate to identifying Security Threats. This mostly relates to layer 7, which is much more complex than ports and protocol based detection. The idea is; if you don't know what you're looking for (presumably a 0-day or unknown threat), then how would one find it? The answer is, research (aka analyze) the data. This ranges from Flow Data (which can date back months/years) to Packet Captures, to even Real Time Deep Packet Inspection (all relating to SIEM Solutions). In these scenarios, you would be looking for the needle in the haystack, but the needle is not clearly defined. You would have to work to identify and define it. So research does relate to identifying illegal/commercial/malware activity. Organizations that understand this are working towards implementing (or have already implemented) real time adaptive security models to mitigate these threats. This will allow them to not only identify and attempt to stop unknown Security Incidents, but also effectively investigate Incidents (forensics).

I think this comment is quite misleading. Your average IT Security Group within an organization is not a 'miniature NSA group'. The difference is where Data is collected and monitored.

Your average IT Security Group is focused on their own Internal network. This includes all Internal and External Traffic/Communication going to/From the Internal Network. The reality is, most Security Threats come from an internal source [1]. So yes, your average IT Security Group is interested in monitoring, analyzing, and sometimes dropping internal Traffic. This allows the Organization to track and respond to Data Breaches and Security Incidents. The overall insinuation of this comment seems to be that this is Evil and a Violation of your Privacy (Spying!). But if you've ever worked with (or used Services provided by) any Organization that has a handle on Security, you've likely signed a User Agreement Form (or similar), which clearly states what is going on. So nothing is hidden, and when you think about it, this is a logical reaction to the realities of Security in today's Digital Age. If you can't trust people, then it makes sense to implement checks and balances. Instead of thinking about it from the perspective is a User, think about it from the perspective of a Service Provider, and it makes a lot more sense. If you think this is Unjust, then the solution is simple. Provide your own services and control your own Destiny.

A 'miniature NSA group' is (presumably) focused on External Networks and External Data Sources. And I say presumably because it is not really clear what you mean by 'miniature NSA group', but the insinuation is clear. So this is very different from your average IT Security Group, and it is not correct to insinuate that they are one and the same.

[1] http://www.itproportal.com/2013/10/15/security-experts-no-su...

From my understanding (which may be limited), treble damages only apply when someone willingly infringes on a patent. So this would be a scenario where someone identifies a patent that relates to what they're building, but they build it anyway. This is very different from identifying existing patents specifically to ensure one does not infringe. In this second scenario someone identifies a patent that relates to what they're building, so they modify what they're building as not to infringe. In some (extreme) cases, this might mean the project should be abandoned. In other (not so extreme) cases, this might mean you need to change one (or more) aspect(s) of the project. In any event, and aside from the legal aspects, I think it's a good exercise for anyone building something. You might avoid future legal issues, you might become more aware of where technology is going (vice a perspective built on currently released products), and it might help you innovate further. Brain food.

I believe that patent trolls "win" when everyone is too scared to stand up for what they believe in. Plain and simple, if people don't take a stand, then things won't change. And I don't necessarily mean just taking a stand in court, I'm talking more about how we (as developers and innovators) react to the issue. I agree that leaving the US will probably lower your chances of becoming a patent troll victim, but everything is relative. Maybe you're building something truly novel and innovative and you want to protect it? Would this outweigh the risk of becoming a patent troll victim? I guess it depends on what (and where) you're building.

There are a few different reasons I do not agree with this comment. For one, I refuse to subscribe to the idea that it's OK to run away from the problem and let patent trolls win by default. I'm the kind of person that stands up for what they believe is right, and thus I would prefer to stand and fight a patent troll. I applaud the organizations out there that are taking a stand (NewEgg, Rackspace, etc). You win some, and you lose some, but in the end I think it's important that people take a stand for what they believe is right. Another reason I do not agree relates to fragmented markets/laws outside of the US. While I think many will agree that the US Patent System has many problems, the one thing it does do well is remain consistent. When you look at the landscape outside of the US, it becomes very fragmented and inconsistent. You may or may not have rights. You probably won't get sued by a patent troll, but you might get ripped off. As an example, consider the Samwer Brothers and their approach towards respecting intellectual property. Granted, this is the other (extreme) end of the spectrum, but it's something to consider. So while the US System does have some problems, there are also some positives that can actually work in your favor. My takeaway from the entire issue; Do your own due diligence. I'm not a Lawyer, but I do know how to search the USPTO Database for Prior Art. It's not rocket science, anyone can do it. If you are a founder, and you are worried, spend some time researching it. I recently made a pretty major UX change to one of my projects based on this advice. I identified a (Microsoft) patent that related to what I was building, and I made sure that my upcoming product does not infringe. Of course one cannot be expected to catch all prior art, but I believe it should still be included in the process at some level.

Here is the original twitter dev blog post if anyone wants to see it [1]. I hope this does not come off an condescending and negative, but my honest reaction is "What took so long"?? It blows my mind that it took 7 years to realize/implement this feature.

One of the main reasons I don't regularly use Twitter is because there is too much white noise. It's hard for me to find information of value because the comments are all over the place. Even when I follow a strict set of People specific to an Industry or a Topic, create specific lists, etc; it's still too much white noise (example; interesting post right next to what someone else had for breakfast).

I am actually quite frustrated with the entire thing. Being someone interested in Development and Solving Problems, I know this can be better. And on that front, it's great to see that this feature finally exists. But there is so much more that could be done to make it even better. It's frustrating because the issue relates to a core Twitter experience, which (under [2] API v1.1 Developer Rules of the Road section 1.5) cannot be replicated. So the end result, I'll probably just have to wait for the customer feedback loop process to complete (which likely takes a long time). Hopefully in the future I'll see some of the features that I had once hoped to build myself. Until then, I probably won't be a regular Twitter user. Frustrating.

If anyone at Twitter reads this, I would be more than happy to describe in detail some of the ways that I think the timeline can become more relevant and valuable. I've talked about it here on HN (project name is InfoStream), and it basically relates to a correlation of GeoLocation Data and Time with relation to Real World Events.

[1] https://dev.twitter.com/blog/introducing-custom-timelines

[2] https://dev.twitter.com/terms/api-terms

Another thing to consider is what constitutes a karma point. I don't have any statistics to validate, but it seems that posting new submissions rewards more karma points than responding to submissions. Maybe the Admins/Mods could run some stats and see if this is true or not. While I do not personally care about karma points (I'm here because I actually enjoy the community), basing the ability to vote (as in, influence the ranking of what is presented) on a single metric that does not differentiate between submissions and comments likely results in a skewed representation of the community.

To put it simply, if you want lots of karma points, don't bother responding to submissions (presumably in an attempt to help someone with a problem, or contribute to the conversation). Instead just find some "hot" controversial articles on some other tech related news sites and submit them instead. If this is true, then it should not be surprising that there is more "white noise" here at HackerNews, as this approach facilitates submitting stories instead of contributing to conversations.

My recommendation (if anyone cares), break karma points up into two separate values, one related to submitting articles/stories (which is valuable), and another related to submitting comments (which is also valuable). Then I would remove any reference of points from the system (make them hidden from users) as to remove any desire to "game the system" for points. This would result in a system where points do not influence how people contribute to the community.

I think it starts with support/backing from stakeholders, perhaps the founders or someone in a position to dictate/enforce policy. Once the stakeholders are on board, then I think the next step is to decide if you want to implement a physical solution (aka Folder/Binder) or a digital solution (aka Software, or a Software related Process), or perhaps a combination of both. Each organization will be different, so the best choice(s) would likely depend on facilitating existing policy/process or existing practices/culture. For example, if there are remote workers, then a physical solution (aka Folder/Binder) might be a bad idea. Another example, if IT security is an afterthought, or the IT Infrastructure is not controlled/managed then a digital solution (aka Software based) might be a bad idea. It all depends on the situation/organization, so this will be a call that you need to make. In terms of managing the passwords, I would recommend a role based distribution on a need to know basis. In other words, if there is no reason for all the employees to know all the passwords, then do not give them all the passwords. Just give them the passwords they need to perform their job functions, and secure the passwords that they do not need elsewhere. Sometimes (especially in a startup or when the workforce is small), the lines between roles can be blurred, so your mileage may vary. But the general rule of thumb is the same; only give out what you need to give out at a minimum. I would also recommend setting and enforcing password policy. From my experience, the standard is 16+ characters, one upper, one lower, one special, one number, no words, no re-using, and it must be changed every 60-90 days. Many IT Systems allow you to set and enforce this via policy, for example in a Windows Environment you can set/enforce password policy via Active Directory. Another example, in a Unix/Linux Environment, you can use chage / passwd (or modify the shadow file directly, not recommended) and PAM. I would also recommend to audit frequently. I think the most important aspect of creating/enforcing policy is to let everyone know that it's nothing personal. Properly implemented security practices can be a pain in the ass. But effective Security is essential to protecting your assets. Getting the workforce on board is key. In most scenarios, your weakest point is internal (weather it is realized/intentional or not).

I am always paranoid when it comes to technology and money, and this will be no exception. BLE (Bluetooth Low Energy) has been around for 2-3 years now, but I still consider it to be in it's infancy. This is especially true when it comes to security. A quick Google Search produced two examples [1] and [2] of potential security flaws with BLE pairing and authentication, and I'm sure there are many more I'm not aware of. Building new payment technology based on new and cutting edge communication frameworks does sound exotic and cool. It's probably one of those "cool points" that gets investors excited. But for the security minded folks out there, this is likely a red flag. Instead I see it as building payment related technology on an un-proven communication framework, and it just does not sound like a great idea. And it is because of this that I will probably never personally use something like Coin regardless of how useful it might be. All it takes is one person to create an effective exploit, and there goes both your money and your trust in the Service. In any event, good luck to Coin with this new Product, and I hope they prove me wrong. If they are looking for a recommendation (which I'm sure they're not), I would recommend a sharp focus on securing the BLE connections between the Coin Wallet and the Smartphone Device.

[1] http://lacklustre.net/bluetooth/

[2] http://eprint.iacr.org/2013/309.pdf

Systems / Network Engineer

The Open Patent Foundation, a 501(c) Non-Profit with 2 specific Goals.

1. A Community Driven approach towards creating 'Open Patent Licenses' similar to existing Open Source Software Licenses (likely a multitude of different licenses that one could use depending on their goal). These Licenses could be used for existing or future Patents, by both Individuals and Legal Entities. The Key here is that the Community votes to choose the Rights, Capabilities, and Limitations of each Open License.

2. A Community Driven approach towards assisting with the actual Patenting of Submitted Technology (or assisting with the Cost / Filing) as provided by, and voted on by the Tech Community. Patents would be granted to the Submitter of the Innovation (they get credit), and then assigned an Open Patent License (everyone can use the Technology freely). Key here being that the Community votes to choose what they want to see Patented.

This is my vision to stop Patent Trolling independently of the Legal System (which works too slow). Crowdsource the Innovations and Patent them with an Open License, thus opening the technology to everyone in the future. We can't stop the Trolling of Existing Patents, but if we draw a line in the sand today, we can stop the Trolling of Future Patents by Patenting the Innovations first and opening them to the Community for Free Use.

While this is a noble cause (IMO anyway), I am still at the point of my life where I need to work 8+ hours a day to pay the Bills, and thus I'm not at the point of starting this Non-Profit (though I do own the Domains, and I have created a Website, as well as considered an Indiegogo Campaign)

I didn't realize they were still working on it, saw no E-mail so I deleted the Video without looking at the stats. Oops!

I'm not sure exactly what you're envisioning, but I've been working (on and off) a side project that sounds very similar. The name I have is InfoStream (not Trademarked), and the domain is infostre.am (not currently in use). I will E-mail and tell you more about what I was envisioning in terms of my project, and we'll see how it matches up with your vision. If we have a match, maybe we can work on it together (or maybe I can contribute somehow). The problem I came up with was Monetization, specifically on the Twitter Platform. Twitter seems to be the best source of real time information, but when they introduced API 1.1 and the (IMO) extremely gray 1.5 rule (do not replicate the core twitter experience) I placed this project on the back burner. It just does not make sense to dedicate time to a project on a platform that will likely pull the plug [1]. In many ways, the vision I have (InfoStream) is replicating the core Twitter experience. I find Twitter's approach towards filtering data (lists) and presenting data to the user (single context feed) to be extremely weak, and ripe for innovation. Yet delivering this information is the core Twitter experience, and thus even though I think I can provide methods to deliver information better (more contextually accurate, more valuable), this is not what Twitter wants. So I end up where lots of other people have ended up; Could build something cool on Twitter, but it's just too unstable from a Developers perspective. If you can think of other Sources for real time data that are not as controlling, more trustworthy, and/or easier to Monetize, I'm open to trying a different approach. Unfortunately, I don't think Twitter is a good choice. And I am hoping that an IPO will change things (but I'm not sure).

[1] http://www.linkedin.com/today/post/article/20130417052642-32...

Understood. Hiring is a two way street, it needs to work for both sides. It's unfortunate how this turned out. But hey, everything happens for a reason right? Maybe it was not meant to be because something else awesome is right around the corner. If you are actively looking, I hope you find something that makes you happy! Take it easy.

I can tell you're frustrated with this Project, but I still think you deserve some congrats. Good job! It's not easy to build something and get that much traffic. I think the frustration stems from the platform it's built on, and how hard it is to monetize on that platform. Since the content is basically given away for free, advertising is your only option. And since they advertise as well... it’s tough to pull it off. I can think of three basic options here (and I'm sure there are many many more):

1. Keep it running, keep it free, and use it as a "Bullet Point" project to increase your perceived value on other projects that have the potential to monetize more successfully

2. Go the complete opposite and just start charging money for it, and see what happens. Of course you risk losing traffic and/or the whole thing imploding, but you never know until you try

3. Just scrap it and re-use the Tech to build a different product that is focused on a niche market that you believe can monetize better. Perhaps News related businesses that would find value in an easy /easier way to find Images for the stories they write

I completely agree. Using option 3 has its own set of con's, and this is one of them. Many Users have been misused/tricked in the past and don't like the idea of associating a new (aka unknown) App with their Social Media Accounts. For all they know the App will steal their data and spam their friends. This is in line with some of the feedback I get when validating with potential customers.

You may have hit a sweet spot there with option 2. Keep us updated! An interesting Metric would be comparing the Bounce Rate between these options above (ala A/B Testing).

I had a completely different experience. I've been in contact with Facebook about potentially working there (Engineering Side) and I would describe my experience as pleasant, respectful, and interesting. I've learned a lot about how Facebook approaches problem solving in their environment, and I'm impressed. From an Engineering perspective, I'm equally impressed with their architecture and the solutions they've built. Not sure if the OP is asking for advice, but I'll give you some; If you want something in life, you have to go for it. Sometimes this means you have to sacrifice something and/or work a little harder. If you can't put in 10 hours for the opportunity to work there, what kind of contribution will you make to their organization? Will you take an initiative to find problems and solve them? Or will you complain about having to do things, and bring a negative attitude? I don't know the answer (and I'm not implying anything), but one can only imagine the picture you've painted with that response. I've been working 10 years to position myself for these types of opportunities. 10 hours is like a drop in the bucket.

I have two alternating schedules because I work an Industry Job in addition to my Project(s). The first half of the week (3-4 days alternating) is dedicated to my Project(s). I work 10 Hour Days from Home, Lunch Break and all. The last half of the week (3-4 days alternating) I work my Industry Job, 12 Hour Shifts (Network Engineer) from 6am to 6pm. I'll usually work an additional 2 Hours on my Project(s) when I get home. So I'm looking at around 82-86 Hours a Week. Pretty wild schedule. I'm moving to San Jose soon so this will all change (finding a new Industry Job and hopefully finding success with some of these Projects)

Great Article, thank you for sharing. It's interesting to follow a Product Launch and see what works / what doesn't work. I like how you've integrated a specific UX into the Product. Right now the Signup is probably one of the most important aspects to focus on (as you onboard Users). Choosing to skip E-mails (and E-mail verification) for a faster signup lowers the entry point barrier and makes the UX more enjoyable. This is something I'm currently working on with my App (the initial Signup Process). I've performed some customer validation and the results were in line with my assumptions. The preferred experience seems to be minimal time investment, and minimal effort. Following this train of thought, here are few basic options:

1. User manually inputs an E-mail Address and Password (commonly w/ E-mail Verification) 2. User manually inputs a Username/Password (less to type, no Verification needed) 3. User taps twice and uses Social Media Integration (example, Facebook Login)

Of course each of these has Pro's and Cons. I will follow Popcorn and see how it works with the second option. I'm leaning towards the third option (minimal time investment), but I'm concerned about perceptions of the associated Social Network(s) and how that might impact the User's desire to create an account. For example, if a certain Network is "not cool" with the younger generation, and you present the "not cool" Network as the Logon method, would that make the App also "not cool"?

I can't speak for anyone else, but here's my thoughts on it; I have Solaris and Oracle experience in large enterprise environments, but it's not something I would consider at a Startup stage. And I'm not anti-Oracle by any means, it just comes down to maximizing my resources. For Oracle, you have these huge up front costs and buy in, and then you consider that there's newer (aka cooler) technology out there that has been proven to work (aka scale) and its way cheaper if not free. And then you consider the shift towards cloud based service delivery and the concept of on demand resources and pay per use. For the "startup mentality" it just seems like a no-brainer to start out with the cheap/free stuff that works, pay per use, and minimal buy in. Best bang for the buck.

So then you build it, it's running, and it grows. And then like any IT solution you build, you have this "lock-in" factor where you've built something on a specific platform in the cloud (or whatever) and it's painful to move to something different. This is compounded as the Userbase (and Dataset) grows bigger and bigger. So you just keep it going as long as you can and keep scaling, and I would guess this is why nobody in the Startup world uses Oracle.

If Oracle wants to power more Startups, Oracle needs to provide an affordable product that Startups choose to use from the start. They would probably kill it if they developed their own version of AWS. Seems that for most of the people I talk with, Oracle is synonymous with Enterprise, not Startups or new innovative technologies. So in some ways, the perception of Oracle and who uses their product might also play a factor. The knowledge and skill requirements are somewhat of a gray area for me, as any approach requires knowledge and skill to implement. I guess I wouldn't describe one approach as requiring more knowledge/skill than another (they all require knowledge/skill to implement, maintain, and scale).

I agree with lots of the replies here; Something else to consider is your product itself and how it's distributed. For example, releasing a Mobile Web App would probably make the domain name more important than releasing a Native Mobile App. In the case of a Mobile Web App, the domain becomes the distribution channel, and in some ways could be considered a part of the Product. In the case of a Native Mobile App, the domain becomes more of an information source and marketing tool while the Product itself is distributed via App Stores. Right now I'm working on a Native Mobile App for both iOS and Android, so an .io domain was fine with me (bought the .co anyway, the .com is being squatted). On another project, the Product is a Mobile Web App, so having the .com was important.

Ironically, I've found the availability of a domain name to be one of the leading deciding factors in naming a Product. Logically, I would think that the Trademark Status is more important, but 99% of the time the Trademark is Available while the .com is being squatted. Sucks.

I should also note that ICANN is about to roll out the new gTLD's. You can read more about it here: http://newgtlds.icann.org/en/ I would expect that over time, the release of new gTLD's will change the perception of a .com being "better" than other domains.

First off, Congrats on starting your own Co-Working space. That's no easy task, and I commend you for building the startup ecosystem in your area. I see where you're coming from, you want to protect all the people that use your co-working space. Regarding the one year grace period, I should just state that Mr. Thomas (the IP lawyer) undoubtedly knows more about Patent Law than I do. But I think the question should be explored further, because I do not really agree with that insinuation. I should also consider that I was not there, and thus don't want to presume anything (I dont know what was said). I think the best way I can help is just to explain my own understanding of how the AIA (America Invents Act) impacted the grace period, and let you decide (or correlate with your own research). From what I understand; Previous to the AIA, the grace period applied to "all disclosures", meaning that the invention could be disclosed by someone (or some entity) other than the inventor, and still be considered a Publication for the inventor. After the AIA, the grace period only applies to the inventors own disclosures, which means the inventor must disclose the invention himself/herself for it to be considered a Publication. Hope this helps!

There are a few different reasons someone might want a software patent at a startup stage. Investors view Patents as an Asset, which can increase your value in their eyes. Legally, they can be leveraged (once granted) to protect a particularly novel idea and minimize competition. They can also be used defensively, protecting you from being sued. They can also be licensed, which means you could potentially generate income.

How much value they have, or if the system works properly is a different conversation entirely. My own personal stance, I'm interested in patents for defensive measures only. Meaning, if someone else tries to sue me over something I created (saying they created it), I have something on my side to protect me.

I should start by stating that I am not a Patent Attorney and you should always get legal advice from an actual Attorney. I'm just an Entrepreneur that does not want to pay Attorney fee's and does it all himself (with no legal background).

From my understanding, the recent change in the patent system (March '13) related to the 'First-to-file' modification, which generally means (assuming two inventors invent the same thing at the same time), the first to file will be granted the patent. This is a change from the first to invent approach, which basically meant whoever could prove they built it first was granted the patent. From my perspective, this just means that you have to take the paperwork aspect of patents a little more seriously, and integrate it into your process at an earlier stage.

I did not watch this presentation, so I'm not really sure what that IP lawyer was talking about. But it sounds like it has something to do with Prior Art. The generalized concept here is that putting information into the public domain makes it "known", which would then imply that it is no longer novel. This information would then become Prior Art, which in some cases could invalidate the invention from being patentable. The important thing to consider here is the documentation or record of who put the information into the public domain. If the inventor put the information into the public domain, then it would belong to the inventor, and thus considered a Publication instead of Prior Art. If someone else put the information into the public domain, then it would belong to whoever provided it, not the inventor, and thus counts as Prior Art against the inventor (and thus, not patentable by the inventor). There is a one-year grace period between the time that you disclose the information, and the time that your publication grace period expires. So my understanding from this is that it actually works in your favor to document your IP, as long as you document it properly, make sure you are recorded as the person documenting it, and you follow through within 1 year. In the example of saying it out loud in a room of people (aka co-working space), then I can understand how it might be difficult to validate and record who actually said what. When documented on paper (or what they call, a Printed Publication), then it would be much easier to validate and record who provided the information. To get more information on how to properly document IP in a Printed Publication, here are some guidelines [1]. Aside from the methods described there, you can also leverage something called a Statutory Invention Registration. This basically means you want to prevent the invention from ever being patented by anyone, so you describe the invention and officially record it with the USPTO, and then waive your right to patent it. You can read more about Statutory Invention Registration here [2].

Getting back to your question, if you are really concerned about someone stealing your IP, then read link [1] and use some of those methods to document your IP. You could also go through the process of actually filing an application. I don't think just running your code constitutes as public disclosure (unless you display it on a projector up on the wall or something). A good rule of thumb is to just be careful about what you share, and whom you share it with. If you feel that it needs to be disclosed, then disclose it properly and protect yourself.

[1] http://www.uspto.gov/web/offices/pac/mpep/s2128.html

[2] http://www.uspto.gov/web/offices/pac/mpep/s1101.html

You are completely correct. And I don't want to add fuel to the fire, but it gets even worse than that. Aside from backdoors and the security of these appliances/devices from a system perspective, what about network connectivity and the transport layer? Only recently, within the past few years [1], has SSL/443 become a requirement for some of the bigger organizations out there. Seems to me that security is often an afterthought. Smart Appliances/Devices run the same risks, and it stands to question; are they connecting securely? And if not, how long will it take them to secure their transport? Because even if that brand new IP-enabled Door Lock is secure from a system perspective, it wouldn't matter if someone can subvert the transport layer, take control, and open the Lock.

One of my Projects attempts to solve this problem for the new generation of IP-enabled Appliances/Devices. I plan to make the process painless and easy. Everyone wins, both customer/consumer and developers/providers. Does anyone want to build it with me?

[1] http://www.washingtonpost.com/blogs/the-switch/wp/2013/10/14...